As more people are turning to the Internet for services such as banking and shopping, there is a growing need for transmitting data securely. Various computer-based approaches have been developed to facilitate secure or encrypted delivery of data from a content server to a client associated with the end user. Several technical issues arise in the course of implementing these approaches. For example, the time it takes to provide the data to people securely is a factor in selecting an approach. Another problem is determining what level of service can be provided to people based on their particular security capabilities.
One past approach is the Secure Sockets Layer (SSL) protocol, now known as TLS. SSL is the most common mechanism on the Internet for facilitating the secure transport of data. In operation, the SSL protocol involves two processing phases. First, there is a key exchange or “handshake” phase, in which the server and client attempt to agree upon an encryption suite to be used for data transmission. After the key exchange or “handshake” is negotiated, a bulk encryption or data transmission phase is carried out in which the desired content is transmitted using the agreed-upon encryption suite.
Both phases may be executed using any of several sets of cryptographic methods. Each set of cryptographic method is termed a cipher suite; a cipher suite is an association of a key exchange mechanism for use in the handshake phase and a bulk encryption mechanism for use in the data transmission phase. For instance, the cipher suite TLS_RSA_WITH_RC4—128_SHA specifies the TLS protocol (SSL v3.1) using the RSA algorithm for key exchange, 128-bit RC4 for bulk encryption, and the SHA message digest algorithm. Similarly, the cipher suite TLS_RSA_EXPORT_WITH_RC4—40_MD5 specifies the TLS protocol using RSA_EXPORT for key exchange, 40-bit RC4 for bulk encryption and MD5 digest algorithm. The first cipher suite provides stronger encryption since it uses larger key lengths. The second cipher suite was designed to comply with certain United States export laws that restrict use of strong cryptography for transmissions outside of the United States.
Thus, different cipher suites may provide different levels of encryption capabilities. Not all servers can support all cipher suites. Similarly, not all clients can use all cipher suites. The handshake phase of SSL is used to negotiate a compatible cipher suite.
In another past approach, server farms are used in conjunction with SSL to serve content to clients. A server farm is a set of content servers that are associated in some way; for example, all the servers are typically commonly owned and operated, or geographically co-located, or protected by a common firewall, or use a single virtual network address.
Each server in a server farm may contain different types of data that have different levels of security. An owner, operator or administrator of the server farm may wish to deliver content from various servers only to clients or users that can use appropriate cipher suites. For example, an administrator may want to allow all SSL users, regardless of their encryption capabilities, to have access to non-confidential data, but may wish to restrict certain users, who have limited encryption capabilities, from accessing highly confidential data. For example, a bank may allow all users to view their respective account information, but may allow only users with higher encryption capabilities to modify the contents of their respective accounts.
In one approach for using a server farm in conjunction with SSL, a Web server in the server farm terminates the SSL connection, and a custom application on the Web server determines if the client is using an appropriate encryption level. There are drawbacks to this method, however. SSL is computationally expensive. The number of SSL transactions that most Web servers can process concurrently is a small fraction of the number of non-SSL connections that the Web servers can process. As a result, major SSL content providers have been turning to dedicated SSL termination devices, which are exclusively responsible for processing SSL connections directed to particular content servers. Examples of SSL termination devices include products available from Alteon, Sonicwall, and others.
However, in this arrangement, since the SSL termination device processes SSL connection, the Web server does not store information identifying the cipher suite that is negotiated between the SSL termination device and the client. Furthermore, known SSL termination devices do not provide means for delivering different content based on the client's encryption capabilities. Therefore, at present there is no way to deliver content from a particular server of a server farm to a client based on the cipher suite or encryption capabilities available at the client.
Based on the foregoing, there is a clear need for a mechanism to route data from a service to a client based on the encryption capabilities of the client.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.